Karl Strickland wrote: Bela> Full disclosure has been sent to CERT for dissemination to other OS Bela> vendors. I am not in a position to publically disclose full details at Karl> you might have cc'd it to 8lgm, to save us a few hours!!! :-) Excuse me, but I'm not feeling particularly friendly to 8LGM right now. I appreciate the bug reports; I do not appreciate the infoterrorism. You have made a point that disclosure "works", but you refuse to adjust your tactics to make it work better. I was not blowing smoke when I asked you to delay the advisories. We could have had the fixes in place, ready to download, with proper MD5 checksums, proper install scripts, etc., if you'd been willing to negotiate. All that aside, it is not my position to send out full disclosure, much as I might like to. What I sent to CERT was properly channeled through SCO's CERT contact. CERT is a recognized and official carrier for such materials. 8LGM is, I don't know, some former "black hat" types who are trying pretty hard to wear what looks like a "white hat" these days, but who can tell? If CERT believes in you then I assume you'll be receiving a copy of my paper from them; if not, well, I know you're smart enough to figure it out anyway. Bela> Your pt_chmod is safe if it coredumps when run as `pt_chmod < Bela> /etc/termcap`. If not, it might or might not be safe. Ask your OS Bela> vendor, "trace" or "truss". Karl> talking of trace, is sco's trace broken? our copy at least, seems to Karl> miss out system calls. eg for pt_chmod, trace never shows chown(2) Karl> being called; but if you disassemble it or single step it with adb, Karl> you can see that it does actually get called. RTFM -- our trace depends on a symbol table. If you get anything at all out of a pt_chmod trace, it's because of the (unstripped) shared library it uses. The COFF shared library doesn't cover every system call: those calls which are really just kernel stubs (move argument into register, trap into system) are statically linked because there was no space benefit, and a performance penalty, to calling them through a call table. (Yes, this means that the people who designed COFF shared libraries didn't understand all the potential benefits of shared libraries -- oh well -- probably one of the reasons ELF was developed). Karl> Well done for getting those patches out so quickly. Thanks, I guess. (and in another message) Karl> 8LGM have reverse engineered SCO's pt_chmod patch, and will be making Karl> exploit details available on Monday, along with exploit details for Karl> the (now patched) SCO problems reported last week. See, there you go again. Have a little patience. Let the fixed code propagate for a while. Give administrators in far off corners of the world a chance to hear about this and put up defenses. Also, let the gory details circulate via CERT for a while -- just because SCO has issued fixes does not mean there aren't other vendors whose code is still vulnerable. If you think this leaves out the freeware community, think again. The people who maintain the various login suites and other such publically available utilities should be in contact with CERT just as commercial vendors are; they should receive this information through the same relatively secure conduits. They should have a chance to examine their code and if necessary, distribute corrected binaries and/or sources before disclosure. (I realize that distributing fixed sources is very similar to disclosure, but it's not quite the same as posting exploitation scripts). As usual, not speaking for SCO... >Bela<